XML printer system with RFID capability

ABSTRACT

An XML system ( 10 ) configured to print bar code labels, tags, tickets, cards, or other media, and/or encode RFID devices embedded in media, based upon an extensible markup language (XML) input data stream. The XML system includes a computer system ( 12 ) operatively coupled to a network ( 44 ). The system further includes a barcode rendering engine configured to generate a printable representation of the bar code label, tag, ticket, card, other media, and/or generate encoding information for an RFID device ( 62 )

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based on International Application No.PCT/US04/015499, having an International filing date of May 17, 2004,and claims the benefit of priority from and is a continuation-in-part ofapplication U.S. Ser. No. 10/332,604, filed Oct. 20, 2003, now U.S. Pat.No. 7,025,268, entitled XML Printer System, which is based onInternational Application No. PCT/US02/36322, having an Internationalfiling date of Nov. 13, 2002, which is a continuation-in-part ofapplication U.S. Ser. No. 10/197,014, filed Jul. 17, 2002, entitledNative XML Printer, now U.S. Pat. No. 6,540,142, which claims thebenefit of priority from the following provisional applications: 1)provisional patent application U.S. Ser. No. 60/345,389, filed Jan. 4,2002, entitled XML Printer Technology, and 2) provisional patentapplication U.S. Ser. No. 60/341,427, filed Dec. 17, 2001, entitled BarCode Labeling Systems Having Machine Readable Standards. Provisionalpatent application Ser. Nos. 60/345,389 and 60/341,427 are incorporatedherein by reference in their entirety.

This application also claims the benefit of priority from and is acontinuation-in-part of application U.S. Ser. No. 10/601,213, filed Jun.20, 2003 now U.S. Pat. No. 6,908,034 entitled XML System, which is acontinuation-in-part of application Ser. No. 10/348,422, filed Jan. 21,2003, now U.S. Pat. No. 6,655,593, entitled Native XML Printer, which isa continuation of application Ser. No. 10/197,014, filed Jul. 17, 2002,entitled Native XML printer, now U.S. Pat. No. 6,540,142.

STATEMENT REGARDING COPYRIGHT RIGHTS

A portion of this disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice Patent files or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF THE INVENTION

The present invention relates generally to a method and apparatus forprinting media, such as tickets, tags, cards, barcode labels, sheet fedpaper, continuous and fan-folded paper, plastic media, and for encodingRF (Radio Frequency) identification circuitry (RFID) that may beembedded in media, and more specifically in one embodiment, to an XML(Extensible Mark-up Language) printer that prints such printed mediaand/or encodes RFID devices based on an AL data stream using existingZPL-based (Zebra Programming Language) format template.

BACKGROUND

Printer systems for printing barcodes and for transmitting data to abarcode printer are known. However, many such systems use proprietarymethods of data encoding, and therefore such methods cannot be usedinterchangeably with other barcode printers. Also, known data encodingmethods typically render the underlying data unreadable by humans. Whilethis presents no impediment to the computer systems, it may beburdensome to humans attempting to review, debug or understand certaindata appearing in the underlying barcode element names. In that regard,XML is an open standard that is being adopted by many business entitiesand is human-readable. Use of XML may avoid many of the problems andpitfalls associated with non-human readable methods.

Barcode labeling is used extensively in many facets of commerce. Inparticular, packages or merchandise shipped from one destination toanother are identified by the shipper by a specific barcode label.Conversely, merchandise received may also be identified and entered intothe receiver's inventory system by use of the barcode label. Often, thereceiver of merchandise may dictate the form and content of the barcodeapplied by the shipper. This is referred to as “compliance labeling.” Ofcourse, merchandise need not be shipped to avail itself of the benefitsof barcode labeling. For example, inventory control systems makeextensive use of barcode labeling to track and monitor various goodswithin a facility or between facilities.

Compliance labeling is typically used by buyers of merchandise havingrelatively large market power or purchasing power. Because of theireconomic power, they may be able to dictate the form and content of thebarcode labels applied to products provided to them by their suppliersor vendors. Although this may be burdensome to the supplier, if thesupplier desires to do business with the buyer, they must comply withtheir demands with respect to labeling. For example, large retailers,such as Wal-Mart, Inc., not only have the ability and purchasing powerto require that suppliers meet their compliance labeling demands, butmay also fine suppliers who fail to comply with the labelingrequirements.

Further, such barcode labeling requirements may change at the whim ofthe entity demanding compliance. Accordingly, the supplier mustimplement the new labeling requirements and test the modified barcode toinsure that it meets all specifications. This is relatively inefficientand time consuming. It is also prone to errors, which may translate intomonetary fines.

Radio Frequency Identification (RFID) is increasing being used inaddition to or in place of barcode labeling, to identify products asthey move through the supply chain and on to consumers. Compliancelabeling is being extended to include the application and encoding ofRFID tags to pallets of goods, cartons, and individual products. Dataabout the products can be written to the tags and/or read from the tags.Data such as a product identification number can be stored on the tag,while data such as a unique tag identification number (which serializesthe tag and associated product) can be retrieved from the tag.

A need exists to provide an open standard for defining barcode labelinginformation that is self-validating and which does not requiresignificant software programming changes to implement a change in formor content of a barcode label. A need also exists for use of a format inwhich to provide data to a barcode printer where the data isunderstandable by a human reading the data.

A further need exists to permit an enterprise resource planning system(ERP) to format its data for transmission to a barcode printer system inXML, while additionally making use of existing ZPL format templates thatgovern the layout of the label and/or by making use of a pure XML formattemplate that uses XSL (extensible stylesheet language) to govern thelayout of the label to be printed. Additionally, a need exists for useof a format in which other data, such as RFID data, may be supplied to adevice to effect encoding of the RFID data into embedded RFID circuitsor other automatic identification devices. A need exists to return RFIDdata read from an RFID circuit to an ERP system or other host computersystem.

BRIEF DESCRIPTION OF THE DRAWINGS

The features of the present invention which are believed to be novel areset forth with particularity in the appended claims. The invention,together with further objects and advantages thereof, may best beunderstood by reference to the following description in conjunction withthe accompanying drawings.

FIG. 1 is a high-level hardware block diagram of a specific embodimentof an AL system according to the present invention;

FIG. 2 is a high-level software block diagram of a specific embodimentof an XML system;

FIG. 3 is a combined high-level software block diagram and data flowdiagram of a specific embodiment of an XML system;

FIG. 4 is a high-level software block diagram of a specific embodimentof a bitmap/barcode and/or radio frequency identification (RFID)rendering engine;

FIG. 5 is a specific representation of a barcode label produced inaccordance with the XML system of FIGS. 14;

FIG. 6 is a specific example of an alternate embodiment of an XML systemconfigured as a barcode and/or RFID rendering server;

FIG. 7 is a high-level software block diagram of a specific alternateembodiment of an XML system;

FIG. 8 is a combined high-level software block diagram and data flowdiagram of a specific alternate embodiment of an XML system; and

FIG. 9 is a specific representation of a barcode label produced inaccordance with the XML system of FIGS. 7-8.

DETAILED DESCRIPTION

In this written description, the use of the disjunctive is intended toinclude the conjunctive. The use of definite or indefinite articles isnot intended to indicate cardinality. In particular, a reference to“the” object or thing or “an” object or “a” thing is intended to alsodescribe a plurality of such objects or things.

Referring now to FIG. 1, a specific embodiment of a high-level hardwareblock diagram of an XML system 10 is shown generally. In the embodimentof FIGS. 1-6, the native or natural “language” of the system is XML,thus the XML system 10 may be referred to as a “native XML printer.” TheKNL system 10 includes a computer or processing system 12, whichincludes various hardware components, such as RAM 14, ROM 16, hard diskstorage 18, cache memory 20, database storage 22, and the like (alsoreferred to as “memory subsystem” 26), as is known in the art. Thecomputer system 12 may include any suitable processing device 28, suchas a computer, microprocessor, RISC processor (reduced instruction setcomputer), CISC processor (complex instruction set computer), mainframecomputer, work station, single-chip computer, distributed processor,server, controller, micro-controller, discrete logic computer and thelike, as is known in the art. For example, the processing device 28 maybe an Intel Pentium® microprocessor, x86 compatible microprocessor, orequivalent device.

The memory subsystem 26 may include any suitable storage components,such as RAM, EPROM (electrically programmable ROM), flash memory,dynamic memory, static memory, FIFO (first-in first-out) memory, LIFO(last-in first-out) memory, circular memory, semiconductor memory,bubble memory, buffer memory, disk memory, optical memory, cache memory,and the like. Any suitable form of memory may be used whether fixedstorage on a magnetic medium, storage in a semiconductor device orremote storage accessible through a communication link.

A user interface 30 may be coupled to the computer system 12 and mayinclude various input devices 36, such as switches selectable by theuser and/or a keyboard. The user interface also may include suitableoutput devices 40, such as an LCD display, a CRT, various LED indicatorsand/or a speech output device, as is known in the art.

To communicate between the computer system 12 and external sources, acommunication interface 42 may be operatively coupled to the computersystem. The communication interface 42 may be, for example, a local areanetwork, as an Ethernet network, intranet, or other suitable network 43.The communication interface 42 may also be connected to a publicswitched telephone network (PSTN) 46 or POTS (plain old telephonesystem), which may facilitate communication via the Internet 44.Dedicated and remote networks may also be employed. Any suitablecommercially available communication device or network may be used, asis known in the art.

The computer system 12 may be further coupled to a printer system 50.The printer system 50 may include a media/paper control system 52, aprinter driver 54 and a print head mechanism 56. Any suitable printercapable of printing barcode labels may be used, which may includevarious dot matrix, ink jet, laser and/or thermal printers. Of course,dot matrix printers are usually of lower quality and require closermonitoring of the label output. Preferably, the printer system 50 is athermal transfer printer. Such suitable printers, for example, areavailable from Zebra Technologies Corporation of Vernon Hills, Ill., andmay include the Model Xi series barcode printers (XiIII+, 90XiIII+,96XiIII+, 110XiIII+140XiIII+, 170XiIII+, 220XiIII+, etc.), the 2800Series barcode printers, Model Z4M, Z6M, 105SL barcode printers, ModelR4Mplus, R402, R-140 printer/encoders, and others. Any suitable barcodelabel printer may be used.

Alternatively, the printer system 50 may include a “non-printing”mechanism to handle the programming of RFID (radio frequencyidentification) media, which may also receive printed labeling or otherprinted indicia on its surface. The term “printer system” is meant toinclude systems that also include RFID capability although the “RFID”may not be part of the term. Additionally, although the term “barcodelabels” are used herein, this term is not limited to a paper label, andmay include, for example, tickets, tags, cards, sheet fed paper,continuous and fanfold paper, plastic media, media embedded with REIDcircuits, and other automatic identification devices. The presentinvention applies to any type of media,

Typically, such printers may include various motors, label cutters,ribbon handlers, sensors, and the like (not shown). Additionally, suchprinters may include various control inputs or sensors, such as a mediasensor, print head temperature sensor, head open sensor, ribbon sensor,and the like (not shown), as is known in the art. The printer system 50may include one or more additional processors 60, other than theprocessor 28 residing in the computer system 12. Alternatively, theprocessor 28 in the computer system 12, if sufficiently powerful, maycontrol and handle the printer system 50 functions without the need fora separate processing device. Thus, all functions of the printer system50 may be controlled by a computer or processor physically separate fromthe printer system. Greater detail concerning the control of theprint-head may be found in U.S. Pat. No. 5,372,439 entitled “ThermalTransfer Printer With Controlled Ribbon Feed,” issued Dec. 13, 1994, andowned by the owner of the present invention. U.S. Pat. No. 5,372,439 ishereby incorporated by reference in its entirety.

The processor 60 of the printer system may be further operativelycoupled to an RFID transceiver 61. The RFID transceiver 61 may beoperatively coupled to the processor 60 or may be operatively coupled tothe processing device 28 of the computer system 12, as shown by a dashedline in FIG. 1. It is not important to the scope of this invention wherethe RFID transceiver 61 resides or to which processing component it iscoupled.

The RFID transceiver 61 is configured to communicate with an RFIDtransponder 62 and program the RFID transponder. RFID transponder 62 maybe of the “chip” or “chipless” type, and one common form of such an RFIDtransponder, which is often used in “smart labels,” includes an antennaand an RFID integrated circuit (not shown). Such RFID transponders 62include both DC powered active transponders and battery-less passivetransponders, and are available in a variety of form factors. The term“barcode printer” or “barcode system” is used interchangeably hereinwith the term “barcode/RFID system,” “XML system” and the like, and sucha system includes the capability to encode RFID data into an RFIDtransponder, even though the term “RFID” may not necessarily be part ofthe identifying text. The system 12 must have the capability to encodeRFID data into an RFID transponder.

Greater detail concerning RFID transponders may be found in applicationSer. No. 10/001,364, entitled Method And Apparatus For Associating OnDemand Certain Selected Media And Value-Adding Elements, filed Oct. 25,2001, and currently pending, which is owned by the assignee of thisapplication. application Ser. No. 10/001,364 is hereby incorporated byreference in its entirety.

Preferably, the computer system 12 and the printer system 50 are locatedin a common enclosure, but need not necessarily be constructed in thismanner. For example, the computer system 12 may be housed in anenclosure separate and apart from the printer system 50.

Referring now to FIGS. 1-3, FIG. 2 illustrates a specific embodiment ofa high-level software block diagram, while FIG. 3 illustrates a specificembodiment of a combined high-level software block diagram and data flowdiagram. The software described below may be executed by the processor28 of the computer system 12 of FIG. 1. Again, the processor 28 mayperform functions common to both the computer system 12 and the printersystem 50. There may be one or more processors, which may function inconcert or which may function separately. It is not material to thescope of this invention whether the processing or processing functionsare performed by or in the computer system or by or in the printersystem.

The software blocks illustrated in FIGS. 2-3 include an XML (extensiblemark-up language) processor 70 (also referred to as the “XML parser”),an XSLT (extensible stylesheet language transformation) processor 74, anXSLFO (extensible stylesheet language formatting object) processor 78, abit map/bar code/RFD: rendering engine 80, the RFID transceiver 61 andthe printer driver 54 (FIG. 1). Of course, the RFID transceiver 61 maybe used in conjunction with printed labels, or may be used separately.The function and basic structure of the XML system 10 is unaffected bythe inclusion or non-inclusion of the RFID transceiver.

Note that the printer driver 54 is an example of a component describedabove whose function may be performed by either the processing device inthe computer system 12 or the processing device 60 (FIG. 1) in theprinter system 50, depending upon the physical location of theassociated processing device. Again, a single processing device, ifsufficiently powerful, may handle all functions for the XML system 10.

An XML schema repository 82 (schema repository) may provide input to theXML processor 70 while an XSLT stylesheet repository 84 (stylesheetrepository) may provide input to the XSLT processor 74. Also shown is anenterprise resource planning (ERP) system 88, which may be, for example,a warehouse management system that transmits an XML input data stream 90to the XML processor 70. The ERP system 88 essentially initiates therequest to print the barcode label, or encode the RFID data into the REDtransponder 62 and provides the XML data that forms the bar code, RFencoded data, and other variable label or element fields to be printedor encoded. Such variable label fields may include, for example, any orall of the human-readable text and/or characters printed on the label.Of course, any enterprise computer system may be used, and thisinvention is not limited to use with any specific type of enterprisecomputer system.

When referring to the XML data, two basic types shall be referred toherein, namely, the XML value data and the XML element name. The X valuedata is the changeable data or the data that is desired to be printed onthe barcode label or encoded into the RFID transponder, such as the data“1122 Green Street,” which may be part of the XML value datacorresponding to, for example, a shipping address. The XML element namesare part of the KML language semantics where an arbitrary label orelement name may be selected to represent the XML value data, the use ofwhich is defined by the XML language. Typically, the element namesappear between angled bracket (“<element name>”).

As described above, known barcode label and other automaticidentification systems often use proprietary software encoding schemes.Additionally, such schemes are often prone to errors, and the underlyingvalue data is usually unreadable by a non-technical individual. In knownsystems, if an error exists in the underlying value data sent from theenterprise system, or if the data is missing or otherwise incorrect, thebarcode system will print or encode what it is instructed to do, whichof course, produces an error in the barcode label or RFID transponder,rendering it inaccurate or useless.

Moreover, when dealing with compliance labeling, known systems requirenon-trivial changes in the data encoding when the form or content of thelabel changes in accordance with the compliance label demands. Suchchanges in the form or content of the barcode or RFID transponder,again, are susceptible to errors, which in turn can lead to monetaryfines by the entity demanding compliance. Business relationships mayalso be damaged by continued problems in the barcode labeling system,especially if such errors disrupt the business of the compliancedemander.

The present AL system 10 utilizes an open format. In particular, theformatting requirements and the form of the barcode label or RFIDtransponder are all defined in the XML language. Moreover, not only isXML well defined and available for all to use, but non-programmers canunderstand the data and commands in an AL data stream or file (or hardcopy) with minimal training.

Various XML software blocks shown in FIGS. 2-3 are commerciallyavailable. Several different commercially available XML processors 70may be used interchangeably or with little modification. For example,the following commercially available XML processors 70 may be used: “XMLfor C++” available from IBM Corporation, “MSXML3” available fromMicrosoft Corporation, “Oracle XML Developers Kit for C” available fromOracle Corporation, “Expat” available from Thai Open Source SoftwareCenter, Ltd., or “Xerces-C++” available from the Apache SoftwareFoundation. However, any suitable XML processor may be used.

Similarly, several different commercially available XSLT processors 74may be used interchangeably or with little modification. For example,the following XSLT processors 74 may be used: “iXSLT” available fromInfoteria Corporation, “MSXML3” available from Microsoft Corporation,and “Libxslt” available from Gnome. However, any suitable XSLT processormay be used.

Again, several different commercially available XSLFO processors 78 maybe used interchangeably or with little modification. For example, thefollowing XSLFO processors 78 may be used: “XBP” available from RenderXCorporation, “XSL Formatter” available from Antenna House Corporation,and “FOP” available from the Apache Software Foundation. However, anysuitable XSLFO processor may be used.

Still referring to FIGS. 1-3, the XML processor 70 receives the XMLinput data stream 90 from an external source 88. For example, theexternal source may be the ERP system 88, such as the warehousemanagement system. The XML processor 70 essentially parses and processesthe XML input data stream 90 and generates a set of nodes, which may bein a “tree” structure, as is known in the art. Each of the softwareprocessing blocks shown in FIGS. 2-3 act on the nodes of the “tree” toperform their required function. The underlying value data contained inthe XML input data stream 90 from the ERP system 88 is processed andentered into a “label values node tree,” 100 which holds the data.

The following is a brief overview of the operation of the varioussoftware components. First, note that the XML input data stream 90includes text that identifies the name and location of other requiredXML documents or files. One such document is referred to as “XML schema”or “schema.” The schema is used to validate the XML input data stream,including the underlying value data. If validation is successful, astylesheet is applied, as will be described below. The name and locationof the stylesheet is also specified in the XML input data stream 90.Application of the stylesheet is handled by the XSLT processor 74, whichunder the direction of the stylesheet, may transform the underlying XMLelement names and/or underlying value data. Next, the data is processedby the XSLFO processor 78, which handles formatting and “layout” of theunderlying value data, which may include, for example, formatting theunderlying value data in accordance with, for example, font type, fontsize, color, and the like. Next, the underlying value data is processedby the bitmap/barcode/RFID rendering engine 80, which creates a bitmap92 of the barcode label or the programming code sequence for the RFIDtransponder corresponding to the transformed and formatted data. Therendering engine 80 may utilize an “instream foreign object” residing inthe stylesheet to direct creation of the bitmap. The bitmap 92 is thensent to the printer driver 54 (FIG. 1) for subsequent printing of thebarcode label by the barcode printer or to the RFID transceiver 61 forencoding into the RFD transponder 62 (FIG. 1).

As described above, the schema functions to validate the entire inputdata stream 90, in particular, the underlying value data, where errorsmay be typically found. In practice, errors arm often inadvertentlyintroduced when changes are made to the form or content of the bar codelabel.

The name and location of the schema document is contained in the XMLinput data stream 90, which XML input data stream corresponds to therequest to print and/or encode a barcode label. The XML processor 70 inconjunction with a schema validation module 110 validates the underlyingvalue data. The use of schema is cost effective because it preventserrors and omissions with respect to the final output, namely, the barcode label, “shipping label,” or RFID tag transponder.

If the XML input data stream 90 is rejected or flagged as having anerror, an error message may be transmitted back to the source 88. Thismay flag or trigger human intervention to correct the error. Forexample, in this specific example, the source is the ERP system 88. Inthis way, the data is initially checked prior to processing to insurethat it complies with all required label and barcode rules.

This may be particularly beneficial when dealing with compliancelabeling. In known systems, the compliance demander would merely notifythe supplier as to the changes in the compliance labeling requirements.If the supplier then makes an error in interpreting or implementingthese changes or instructions, the labels produced or RFID transpondersencoded and applied to products shipped to the compliance demander mayhave errors, which could jeopardize future business or cause monetaryfines to be applied.

In the present invention, the compliance demander preferably makes thechanges directly to the schema and/or the XSLT stylesheet. For example,if the physical layout of the label has been changed or if element nameshave been changed, the compliance demander will modify the XSLT stylesheet. Similarly, if the underlying value data has been added or deletedor otherwise qualified (e.g., a new acceptable numerical range for a zipcode), the compliance demander may modify the schema. In this way, thesupplier need only modify the output of its ERP system 88 to ensure thatit matches the modified XML input data stream 90. If only the physicallayout of the label has changed, the supplier does not need to make anymodifications at all.

For example, the compliance demander may now require that a nine digitzip code be used rather than the original five digit zip code.Accordingly, the compliance demander may modify the schema to requireboth a first and second zip code field, and the second field will alsobe limited to numerical digits within a certain range, perhaps0000-9999. The compliance demander may also modify the stylesheet toaccommodate that change. In response thereto, the supplier must insertthe added zip code field in its ERP system so that it appears in the XMLinput data stream 90 sent to the XML system 10. If such modification ofthe XML input data stream 90 is not performed correctly, the schema willcause an error to be reported back to the ERP system 88, and the labelwill not be printed or the RFID transponder will not be encoded.

Thus, the supplier need only access the modified schema and/orstylesheet from the repository 82, 84, which is automatically applied tothe underlying value data when received. Essentially, minor changes, andsignificantly, major changes, to the form and content of the barcodelabel or RFID transponder are transparent to the supplier, and suchchanges to the content of the barcode label or RFID transponder arevalidated in accordance with the schema. Accordingly, the supplier neednot incur costs to change the form or content of the barcode label orRFID transponder dictated by the compliance demander, and cannot makeany errors in implementing such changes. If there are any errors, sucherrors would have been inadvertently made by the compliance demander,who could not then blame the supplier.

The schema documents are preferably obtained from the XML schemarepository 82. In one specific embodiment, the schema repository 82 maybe external to the XML system 10 and the computer system 12, and may beaccessed via the network, the Internet, or via any suitable network 43,44 to which the computer system is coupled. The schema repository 82 maycontain a plurality of schema documents. Thus, the XML input datastreams 90 representing the various requests to create a barcode labelor RFID transponder may each specify the name and location of thecorresponding schema in the repository 82. When the request is receivedby the XML processor 70, the corresponding schema may be retrieved fromthe schema repository 82.

In another embodiment, the schema obtained from the schema repository 82via the network 42, 43 may be kept locally, and thus may temporarilyreside in the memory subsystem 26 (FIG. 1), such as the hard disk 18 ordatabase 22. In this way, if the same schema is used for multiple XMLinput data streams 90 or for subsequent barcode label requests, the XMLprocessor 70 need not retrieve the same schema externally via thenetwork 42, 44, but rather, may retrieve that schema from the memorysubsystem 26, which may be more efficient. According to this embodiment,the compliance demander may change or modify the schema in the externalrepository 82 at only certain times. For example, the compliancedemander may change the stylesheet only at 1:00 AM each day. Thus, thesupplier need only update the schema from the repository 82 into thememory subsystem 26 only once per day, for example, after the compliancedemander has performed the schema update. The supplier would then knowthat the schema saved temporarily in the memory subsystem 26 is the mostrecent schema document, at least up until the time that the updating isscheduled to occur.

Regardless of the location from where the schema is obtained, the schemavalidation module 110 performs the checking and validation of theunderlying data. Although the schema validation module 110 is shown as aseparate block from the XML processor 70 in FIG. 2, it is shown in thislocation for purposes of illustration only so that it may be shown onthe drawing adjacent to the label values node tree 100, which is thedata upon which it acts. However, the schema validation module 110 maybe part of and integrated into the XML processor 70, or it may be aseparate and apart therefrom.

Of course, the schema is also an XML document, and thus it is alsoprocessed by the XML processor 70. Accordingly, the result of theprocessing of the schema is the XML schema node tree 114 shown in FIG.3, which is the “memory representation” or working model of the schemathat was processed. The XML schema node tree 114 may be in the form of a“document object model” (DOM), as is known in the art. Further, the XMLschema node tree 114 may reside in cache memory for efficiency, as shownin an XML schema cache 116. The schema validation module 110 and/or theXML processor 70 operate on the data in the XML schema node tree 114 toperform its function of validating the underlying value data inaccordance with the schema document.

As described above, if an error exists in the XML input data stream 90,as determined by application of the schema, an error message may begenerated. If the XML input data stream 90 is validated, the dataremains essentially “untouched.” The data in the label value node tree100 is then processed by the XSLT processor 74 using the XSLTstylesheets.

Alternatively, validation of the underlying value date may be performedaccording to Document Type Definition (DTD) format, rather than use ofschema. Use of DTD is specified in detail in various XML specifications,and is known in the art.

The stylesheet documents are preferably obtained from the XSLTstylesheet repository 84. In one specific embodiment, the stylesheetrepository 84 may be external to the XML system 10 and the computersystem 12, and may be accessed via the network, the Internet, or via anysuitable network 43, 44 to which the computer system is coupled. Thestylesheet repository 84 may contain a plurality of stylesheets. Thus,XML input data streams 90 representing the various requests to create abarcode label or encode an RFID transponder may each specify the nameand location of the corresponding stylesheet in the repository 84. Whenthe request is received by the XML processor 70, the correspondingstylesheet may be retrieved from the stylesheet repository 84.

In another embodiment, the stylesheet obtained from the stylesheetrepository 84 via the network 43, 44 may be kept locally, and thus maytemporarily reside in the memory subsystem 26 (FIG. 1), such as the harddisk 18 or database 22. In this way, if the same stylesheet is used formultiple XML input data streams 90 or for subsequent barcode label orRFID transponder requests, the XML processor 70 need not retrieve thesame stylesheet externally via the network 43, 44, but rather, mayretrieve that stylesheet from the memory subsystem 26, which may be moreefficient.

According to this embodiment, the compliance demander may change ormodify the stylesheet in the external stylesheet repository 84 at onlycertain times. For example, the compliance demander may change thestylesheet only at 1:00 AM each day. Thus, the supplier need only updatethe stylesheet from the stylesheet repository 84 into the memorysubsystem 26 only once per day, for example, after the compliancedemander has performed the stylesheet update. The supplier would thenknow that the stylesheet saved temporarily in the memory subsystem 26 isthe most recent stylesheet, at least up until the time that the updatingis scheduled to occur.

Of course, the stylesheet is also an XML document, and thus it is alsoprocessed by the XML processor 70. Accordingly, the result of theprocessing of the stylesheet is the XSLT stylesheet node tree 120 shownin FIG. 3, which is the “memory representation” or working model of thestylesheet that was processed. The XSLT stylesheet node tree 120 may bein the form of a “document object model” (DOM), as is known in the art.Further, the XSLT stylesheet node tree 120 may reside in cache memoryfor efficiency, as shown in an XSLT stylesheet cache 126. The XSLTprocessor 74 operates on the data in the XSLT stylesheet node tree 120to perform its function of transforming the underlying value data orunderlying element names in accordance with the stylesheet.

Note that although the XSLT style sheet is shown as an input to the XMLprocessor 70 in FIG. 3, the XSLT processor 74 processes the stylesheet.It is initially provided to the XML processor 70 because all XMLdocuments are first processed and placed into the appropriate datastructure for subsequent processing.

The XSLT processor 74 may modify, reposition, and rearrange theunderlying value data or may add to the underlying value data or deletesome of the underlying value data. For example, under direction of thestylesheet, the underlying value data may be rearranged into tableformat or into columns. In particular, the stylesheet may add XSLFOformatting elements and attributes.

After the underlying value data in the label value node tree 100 hasbeen processed in accordance with the corresponding stylesheet, an XSLFOinstance node tree 130 is produced. Again, the XSLFO instance node tree130 may be in the form of a document object module, as is known in theart. The XSLFO instance node tree 130 contains XSLFO commands (layoutinstructions) that directs the XSLFO processor 78 with respect toformatting and layout. The XSLFO processor 78 then interprets the XSLFOcommands and applies such commands to the underlying value data so as toproperly format and layout the underlying value data. The XSLFOprocessor 78 produces the XSLFO area node tree 130, which represents thefinal output of formatting before rendering.

Turning now to FIG. 3 and a code segment shown immediately belowentitled “code segment 1 for an XML input data stream,” the code segment1 illustrates an XML input data stream 90 in hard copy, which may, forexample, be sent to the XML system 10 by the ERP or warehouse managementsystem 88. Line numbering has been inserted for purposes of illustrationonly and is not part of the code.

Code Segment 1 For An XML Input Data Steam    <?xml version=“1.0”encoding=“UTF-8”?>    <?xml-stylesheet type=“text/xsl”   href=“D:\Projects\XML\Native\Docs\ShipLabels.xsl”?>  <labels  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”  xsi:noNamespaceSchemaLocation=      “D:\Projects\XML\Native\Docs\ShipLabels.xsd”>   <label>   <name>Albert Einstein</name>    <address>1234 Relative Way</address>   <city>Princeton</city>    <state>NJ</state>    <zip>08540</zip>  </label>   <label>    <name>Steven Hawking</name>    <address>5678Black Hole Drive</address>    <city>Los Angeles</city>   <state>CA</state>    <zip>90007</zip>   </label>   <label>   <name>Richard Feynman</name>    <address>90 Quantum Circle</address>   <city>New York</city>    <state>NY</state>    <zip>10044</zip>  </label> </labels>

The XML input data stream identifies the schema document as“ShipLabels.xsd,” and that schema document may be found, in thisspecific example, in a directory called “D:/Projects/XML/Native/Docs,”as shown at line 7 in code segment 1. Further, the XML input data streamidentifies the stylesheet document as “ShipLabels.xsl,” and thatstylesheet document may also be found in a directory called“D:/Projects/XML/Native/Docs,” as shown at line 3 of the code segment 1.Of course, the schema document and the stylesheet document may belocated anywhere, for example, as identified by an Internet address.

This specific example shows the underlying value data and element namesfor three shipping labels to be printed. Each shipping label contains anXML element name defined between angular brackets as follows: <name>,<address>, <city>, <state> and <zip>. The value of the first elementname, <name>, is “Albert Einstein,” the value of the second elementname, <address>, is “1234 Relative Way,” the value of the third elementname, <city>, is “Princeton,” the value of the forth element name,<state>, is “NJ” and the value of the fifth element name, <zip>, is“08540.” This is the underlying value data.

Now turning to FIG. 3, code segment 1, and a code segment shownimmediately below entitled “code segment 2 for XML schema,” the codesegment 2 illustrates a specific example of an XML document in the formof the XML schema document specified in the XML input data stream ofcode segment 1. Line numbering has been inserted for purposes ofillustration only and is not part of the code.

Code Segment 2 For XML Schema  <?xml version=“1.0” encoding=“UTF-8”?> <xs:schema   xmlns:xs=“http://www.w3.org/2001/XMLSchema”  elementFormDefault=“qualified”>  <xs:element name=“address”type=“xs:string”/>  <xs:element name=“city” type=“xs:string”/> <xs:element name=“label”>   <xs:complexType>    <xs:sequence>    <xs:element ref=“name”/>     <xs:element ref=“address”/>    <xs:element ref=“city”/>     <xs:element ref=“state”/>    <xs:element ref=“zip”/>    </xs:sequence>   </xs:complexType> </xs:element>  <xs:element name=“labels”>   <xs:complexType>   <xs:sequence>     <xs:element ref=“label” maxOccurs=“unbounded”/>   </xs:sequence>   </xs:complexType>  </xs:element>  <xs:elementname=“name” type=“xs:string”/>  <xs:element name=“state”>  <xs:simpleType>    <xs:restriction base=“xs:string”>    <xs:enumeration value=“CA”/>     <xs:enumeration value=“NJ”/>    <xs:enumeration value=“NY”/>    </xs:restriction>   </xs:simpleType> </xs:element>  <xs:element name=“zip”>   <xs:simpleType>   <xs:restriction base=“xs:int”>     <xs:minInclusive value=“00000”/>    <xs:maxInclusive value=“99999”/>    </xs:restriction>  </xs:simpleType>  </xs:element> </xs:schema>

As mentioned above, the schema is used to validate the underlying valuedata. This entails checking to determine that all required data ispresent, that no extraneous data is present, that the data present iswithin the specified ranges, and the like. Any suitable validationscheme may be specified in the schema, depending upon the application.The XML language is robust and code may be written to handle a vastmultitude of requirements.

For example, the schema document shown in code segment 2 above specifiesthat the underlying value data corresponding to the element name,<address>, must be a string, as defined in the XML Schema specification,as shown by line 5 in the code segment 2. The schema document alsospecifies that the underlying value data corresponding to the elementnames of <name>, <address>, <city>, <state>, and <zip> must also bepresent in the sequence indicated, as shown by lines 9 -15 in the codesegment 2. Further, this specific schema document shown in the codesegment 2 specifies that the underlying value data corresponding to theelement name, <state>, must be one of three states, namely, “CA,” “NJ,”or “NY.” Of course, this is only an abbreviated example, and not allstates have been included for purposes of illustration only. The schemadocument shown in code segment 2 also specifies that the underlyingvalue data corresponding to the element name, <zip>, must be in therange from 00000 to 99999. If any of the above-mentioned schema criteriaare not met by the data in the XML input data stream, the schemavalidation module 110 will reject it, and will preferably return anerror message back to the source 88.

Now turning to FIG. 3, code segment-2, and a code segment shownimmediately below entitled “code segment 3 for an XSLT stylesheet,” thecode segment 3 shows a specific example of an XML document in the formof the XSLT stylesheet document specified in the XML input data streamof the code segment 1. Line numbering has been inserted for purposes ofillustration only and is not part of the code.

Code Segment 3 For An XSLT Stylesheet <?xml version=“1.0”encoding=“UTF-8” ?> <xsl:transform version=“1.0”  xmlns:xsl=“http://www.w3.org/1999/XSL/Transform”  xmlns:fo=“http://www.w3.org/1999/XSL/Format” xmlns:bo=“http://www.zebra.com/2002/XSL/Barcode”> <xsl:outputmethod=“xml” version=“1.0” indent=“yes” />  <xsl:templatematch=“labels”>   <fo:root>    <fo:layout-master-set>      <fo:simple-page-master master-name=“all-labels”>       <fo:region-body margin=“1in” />     </fo:simple-page-master>   </fo:layout-master-set>    <fo:page-sequencemaster-name=“all-labels”>     <fo:flow flow-name=“xsl-region-body”font=“12pt     Times”>      <xsl:apply-templates />     </fo:flow>   </fo:page-sequence>    </fo:root>   </xsl:template>   <xsl:templatematch=“label”>    <fo:block break-after=“page”>    <xsl:apply-templatesselect=“name” />    <xsl:apply-templates select=“address” />   <fo:block font=“bold 14pt Times” text-align=“left”>    <xsl:apply-templates select=“city” />    <xsl:apply-templatesselect=“state” />    </fo:block>    <xsl:apply-templates select=“zip” />   <fo:block>     <fo:instream-foreign-object>      <bo:barcode>      <bo:postnet interpretation-line=“none”>        <xsl:value-ofselect=“zip” />       </bo:postnet>      </bo:barcode>     </fo:instream-foreign-object>    </fo:block>   </fo:block> </xsl:template>  <xsl:template match=“name”>   <fo:block font=“bold14pt Times” text-align=“left”>    <xsl:value-of select=“.” />  </fo:block>  </xsl:template>  <xsl:template match=“address”>  <fo:block font=“bold 14pt Times” text-align=“left”>    <xsl:value-ofselect=“.” />   </fo:block>  </xsl:template>  <xsl:templatematch=“city”>   <xsl:value-of select=“.” />  </xsl:template> <xsl:template match=“state”>   <xsl:text>,</xsl:text>   <xsl:value-ofselect=“.” />  </xsl:template>  <xsl:template match=“zip”>   <fo:blockfont=“bold 14pt Times” text-align=“left”>    <xsl:value-of select=“.” />  </fo:block>  </xsl:template> </xsl:transform>

As mentioned above, the stylesheet is used to transform the data. Inthis specific example, the stylesheet of the code segment 3 defines twotypes of namespace, namely, a “bo” type object, which is selected to bea “barcode-type object,” and an “fo” type object, which is selected tobe a formatting object, which was described above with respect to theXSLFO processor 78. This permits differentiation between the differentobjects, as is known in the art. The stylesheet may cause some data tobe transformed or even added. For example, the underlying value datafrom the XML input data stream of the code segment 1, namely “Einstein,”“1234 Relative Way,” and the like, is inserted, as indicated by lines40-62.

This stylesheet also causes a variety of “fo” type elements to begenerated, which are designated as formatting elements or XSLFO objects.The XSLFO objects contain layout type commands that the XSLFO processor78 “understands” and processes. Note that all lines of code having aprefix of “fo” are not interpreted by the XSLT processor 74, but rather,are passed on to the XSLFO processor 78.

For example, line 21 of the code segment 3 shows <xsl: templatematch=“label”> followed by <fo:block break-after=“page”> on line 22.This is interpreted by the XSLFO processor 78 to put a “page break”between the three shipping labels specified in the code segment.Essentially a new shipping label is created due to the page break, witheach new shipping label containing the underlying value data specifiedin the code segment 1.

Further, this specific stylesheet specifies that an “instream foreignobject” is inserted, as shown at line 31. Line 31 is shown as<fo:instream-foreign-object> in conjunction with lines 31-37 , whichdefine the instream foreign object. Note that the instream foreignobject is not processed by either the XSLT processor 74 or the XSLFOprocessor 78. Rather, the instream foreign object is passed to and isprocessed by the bitmap/barcode/RFID rendering engine 80. For example,lines 32-36 of the code segment 3 cause a <bo:barcode> element to beinserted that contains the definition of a “postnet” barcode element,which element will later be processed by the bitmap/barcode/RFIDrendering engine 80. At line 34, the XSLT processor 74 causes the zipcode from the XML input data stream to be inserted as the text of the<bo:postnet> element. Alternatively, although not shown in the code, anRFID type instream foreign object may define the encoding forprogramming an RFID transponder.

Now turning to FIG. 3, code segments 1-3, and a code segment shownimmediately below entitled “code segment 4 for an XSLT instance nodetree representation,” the code segment 4 shows a specific example of arepresentation of an XSLFO instance node tree 130 output produced by theXSLT processor 74 in conjunction with the stylesheet of code segment 3,which output is a representation of the XSLFO instance node treeprovided to the XSLFO processor 78. Line numbering has been inserted forpurposes of illustration only and is not part of the code.

Code Segment 4 For An XSLFO Instance Node Tree Representation <?xmlversion=“1.0” encoding=“UTF-16” ?>  <fo:rootxmlns:fo=“http://www.w3.org/1999/XSL/Format”  xmlns:bo=“http://www.zebra.com/2002/XSL/Barcode”>  <fo:layout-master-set>    <fo:simple-page-mastermaster-name=“all-labels”>    <fo:region-body margin=“1in” />   </fo:simple-page-master>   </fo:layout-master-set>  <fo:page-sequence master-name=“all-labels”>    <fo:flowflow-name=“xsl-region-body” font=“12pt Times”>    <fo:blockbreak-after=“page”>     <fo:block font=“bold 14pt Times” text-     align=“left”>Albert Einstein</fo:block>     <fo:block font=“bold14pt Times” text-      align=“left”>1234        Relative Way</fo:block>    <fo:block font=“bold 14pt Times” text-      align=“left”>Princeton,NJ</fo:block>     <fo:block font=“bold 14pt Times” text-     align=“left”>08540</fo:block>     <fo:block>     <fo:instream-foreign-object>       <bo:barcode>        <bo:postnetinterpretation-         line=“none”>08540</bo:postnet>      </bo:barcode>      </fo:instream-foreign-object>     </fo:block>   </fo:block>    <fo:block break-after=“page”>     <fo:block font=“bold14pt Times” text-     align=“left”>Steven Hawking</fo:block>    <fo:block font=“bold 14pt Times” text-      align=“left”>5678 BlackHole Drive</fo:block>     <fo:block font=“bold 14pt Times” text-     align=“left”>Los        Angeles, CA</fo:block>     <fo:blockfont=“bold 14pt Times” text-      align=“left”>90007</fo:block>    fo:block>      <fo:instream-foreign-object>       <bo:barcode>       <bo:postnet interpretation-         line=“none”>90007<bo:postnet>      </bo:barcode>      </fo:instream-foreign-object>     </fo:block>   </fo:block>    <fo:block break-after=“page”>     <fo:block font=“bold14pt Times” text-      align=“left”>Richard Feynman</fo:block>    <fo:block font=“bold 14pt Times” text-      align=“left”>90 QuantumCircle</fo:block>     <fo:block font=“bold 14pt Times” text-     align=“left”>New York, NY</fo:block>     <fo:block font=“bold 14ptTimes” text-        align=“left”>10044</fo:block>     <fo:block>     <fo:instream-foreign-object>       <bo:barcode>        <bo:postnetinterpretation-          line=“none”>10044</bo:postnet>      </bo:barcode>      </fo:instream-foreign-object>     </fo:block>   </fo:block>   </fo:flow>   </fo:page-sequence> </fo:root>

Two main portions of code segment 4 above are briefly described, namely,one beginning at line 4 with the code <fo:layout-master-set> and asecond portion beginning at line 9 with the code <fo:page-sequencemaster-name=“all-labels>. This portion of the code essentially defineswhat a barcode label will “look like” or how it will be “laid-out” andhow the underlying value data will appear in that lay-out.

With respect to formatting the underlying value data shown in codesegment 1, for example, the font attribute of “bold 14pt Times” andtext-align=“left” shown in lines 12-13 will be applied to the underlyingvalue data of “Albert Einstein” so that when the barcode label isprinted, the name of “Albert Einstein” will be printed in 14 point Timesfont, and it will be aligned with the left margin of the barcode label.As is known in the art, may different kinds of formatting instructionsmay be specified, which will be interpreted by the XSLFO processor 78.

Further, this specific example of the representation of the XSLFOinstance node tree 130 contains an instream foreign object, as shown atlines 21-26 of the code segment 4, which instream foreign object may notbe processed by the XSLFO processor 78. Rather, the instream foreignobject may be passed to the bitmap/barcode/RFID rendering engine 80 forprocessing. Note that at this point in the processing, the XSLFOprocessor 78 does not “know” how to print a barcode label or encode anRFID transponder because barcode element types and RFID transponderelement types are not included in the XSLFO specification. Rather, onlythe text information, such as the underlying value data, namely,“Einstein,” “1234 Relative Way,” and the like, as shown in code segments1-2, could be printed on the barcode label as text. With respect tolabels, no actual barcode symbol would appear because the XSLFOprocessor 78 does not “know” how to produce a barcode symbol. The RFIDtransponder would not be encoded because the XSLFO processor 78 does not“know” how to encode a transponder.

The result of processing by the XSLFO processor 78 is an XSLFO area nodetree 140. Note that the instream foreign object shown in the codesegment 4 is not processed by the XSLFO processor 78, but rather, ispassed to the barcode/bitmap/RFID rendering engine 80 in one or morenodes of the XSLFO area node tree 140. The instream foreign objectelement is referred to as <bo:barcode> and is shown at lines 21-26 ofthe code segment 4. The barcode/bitmap/RFID rendering engine 80 receivesthe <bo:barcode> element and processes the code contained in that block.For example, the rendering engine 80 interprets lines 23-24, namely,<bo:postnet interpretation-line=“none”>08540<bo:postnet> as definingthis particular node as being a “postnet” barcode type of element. Manydifferent “types” of barcode symbols may be defined, as is defined bycorresponding industry standards, discussed below.

Alternatively, if the instream foreign object element relates to RFIDencoding, the rendering engine 80 would interpret the instream foreignobject according to specific standards governing the programming andencoding of the RFID transponder 62 (FIG. 2) by the RFID transceiver 61(FIG. 1). Like the elements and attributes of the XML data that specifyhow a barcode is to be printed, such elements and attributes can alsospecify the text and characteristics to be programmed into an RFID tag,such as the RFID transponder 62. Essentially, the rendering inaccordance with the RFID-type instream foreign object governs theoperation of the RFID transceiver 61 (FIG. 1). As such, radio frequencysignals are transmitted between the RFID transceiver and the RFIDtransponder to effect programming of the RFID transponder.

The operation of the RFID transceiver may be according to internationalstandards such as ISO/IEC or according to proprietary specificationsfrom vendors such as Texas Instruments (Tag-it) or Phillips (I Code).For example, operation may be governed by the International Organizationfor Standardization (ISO) specification 15693 for vicinity cards, or byISO specification 14443 for proximity cards. ISO specification 15693describes the physical characteristics, the radio frequency power andsignal interface, and the anticollision and transmission protocol. Thetransmission protocol specification includes the requests and responsesto read, write, and lock the transponder. Note that the ISOspecification 15693 is a preferable applicable standard when RFID labeltags are involved.

The underlying value data to be printed as a barcode symbol is thenumerical data “08540,” as shown in line 24 of code segment, whichunderlying value data is the zip code associated with Albert Einstein'saddress shown in the code segment 1. In this specific example, only thezip code is transformed into the barcode symbol. Of course, any and allinformation may be transformed into a barcode symbol, depending upon theapplication. Also, in this specific example, the instream foreignobjects shown in the code segment 4 only relate to the three zip codesshown in the code segment 1. No other underlying value data istransformed into the barcode symbol in this example.

Also note that the XML system 10 need not necessarily contain the XSLTprocessor 74. In an alternate embodiment, the XSLT processor 74 or theequivalent thereof may be remotely located from the XML system 10 andmay be configured to transform XML data in the XML input stream andprovide the transformed data to the XML system. Accordingly, the XMLsystem 10 may receive and process the transformed XML data intoformatted XML data. Remote or “separate” processing equivalent to theprocessing typically handled by the XSLT processor may be based uponXSLFO instructions contained in stylesheets, which also need not residein or be directly accessible to the XML system 10.

Turning now to FIGS. 2-4 in conjunction with the code segment 4,additional detail concerning the barcode/bitmap/RFID rendering engine 80and the processing of the instream foreign objects will now be setforth. As described above, the rendering engine 80 processes each nodeof the XSLFO area node tree 140 generated by the XSLFO processor 78. Asis known in the art, the XSLFO area node tree 140 is represented inmemory as a document object model. Accordingly, multiple nodes mayexist. For example, one node may contain the instream foreign object,another node may contain associated element names, another node maycontain associated text data, another node may contain associatedattributes, and the like.

As shown in block 150 in FIG. 4, the nodes of the XSLFO area node tree140 are processed. In particular, the rendering engine 80 “knows” how torender or produce the actual barcode symbol or RFID encoding defined bythe corresponding instream foreign object. Commercially available XSLFOprocessors do not “know” how to process such instream foreign objectsrepresenting barcode symbols and RFID transponders, and thus are notable to produce or render barcode symbols or encode RFID transponders.Commercially available XSLFO processors may, however, render text in anacceptable manner and may even render certain types of instream foreignobjects.

If a particular node does not contain an instream foreign object,meaning that it may contain, for example, text data, then this node maybe processed in a “standard” way by utilizing the processing power ofthe XSLFO processor 78 rather than the rendering engine 80, asillustrated in a block 154. In one embodiment, the non-instream foreignobject is provided “back” to the XSLFO processor 78, or the XSLFOprocessor is notified that a particular node in the XSLFO area node tree140 is suitable for processing by it.

Processing of a node in the XSLFO area node tree 140 containing anon-instream foreign object may be processed by the XSLFO processor 78,as described above. Of course, different commercially available XSLFOprocessors render text, for example, into different formats. Forexample, the XSLFO processor referred to as “XSL Formatter” availablefrom Antenna House Corporation, as described above, renders a node intoa WINDOWS “device-independent bitmap” format. The XSLFO processorreferred to as “XEP” available from RenderX Corporation, as describedabove, renders a node into “PDF” format, and the XSLFO processorreferred to as “FOP” available from the Apache Software Foundation, asdescribed above, may also render a node into “PDF” format.

Preferably, the XML system 10 utilizes the “FOP” XSLFO processor 78available from the Apache Software Foundation because this XSLFOprocessor may be configured to “call” a subroutine or other processingfunction when it encounters an instream foreign object that it is notcapable of processing. In particular, this XSIFO processor 78 may be setto call the rendering engine software block 80 described herein, tohandle the instream foreign object that it is not capable of processing.

Next, as shown in a block 160, if the node contains an instream foreignobject representing a barcode or RFID transponder, which is not capableof being processed by the XSIPO processor 78, the rendering engine 80checks to determine if the instream foreign object has a “namespace”specific to this XML system 10. For example, the rendering engine 80 maycheck to determine if the namespace associated with the instream.foreign object corresponds to the “Zebra Technologies Corporationnamespace.” The namespace notation is known in the art. This is shown inline 3 of the code segment 4 as“xmlns:bo=“http://www.zebra.com/2002/XSIJBarcode”>” Thus, as shown inthe code segment 4, the namespace defined above is applied to anyelements having a “bo” prefix. Such elements having a “bo” prefix arethen only available for processing by the rendering engine 80, which“bo” prefix type elements correspond to a barcode-type instream foreignobject. The XSLFO processor 78 will not “know” how to process suchelements.

If the instream foreign object is not associated with the propernamespace, it is passed back to the XSLFO processor 78, assuming that itis not a barcode type instream foreign object because the XSLFOprocessor may be able to process some limited number of instream foreignobjects. This is shown by arrow 162 from the block 160 to the block 154.Generally, however, instream foreign objects exist or are created forthe specific reason that the data associated with an instream foreignobject is very unique in nature (such as a barcode), and thus, manycommercially available or general purpose XSLFO processors can notprocess them.

Note that the commercially available XSLFO processors mentioned hereinare not necessarily incapable of processing all instream foreignobjects. They are, however, incapable of processing instream foreignobjects corresponding to barcode symbols and RFID encoding.

Assuming that instream foreign object has the appropriate namespace, ablock 170 interprets the elements in the instream foreign object todetermine barcode type. For example, the instream foreign object isshown at lines 21-26 the code segment 4. More specifically, the barcodeelement having a prefix of “bo,” indicating the correct namespacecorresponding to a barcode, is shown to have a barcode type of“postnet,” as shown in line 23-24 of the code segment 4, which appearsas <bo:postnet interpretation-line=“none”>08540</bo:postnet>. Note thatlines 41-42 of the code segment 4 show a similar barcode element foranother instream foreign object, namely, the next barcode label to beprinted, which corresponds to the address of “Steven Hawling” shown incode segment 1.

Any barcode type may be specified in the instream foreign objectdepending upon the application. The barcode type is based upon knownbarcode standards. For example, the barcode type is not limited to apostnet type of barcode symbol, and may be, for example, Industrial 2 of5,” “PDF 417,” “UPC,” and the like. The barcode “type” specifies thebasic structure of the barcode symbol to be printed, such as thethickness of the bars, the ratio of the thickness of the bars to thewidth of the space between bars, and the like. Each specific knownbarcode standard is concretely defined.

Next, after the barcode type has been ascertained from the instreamforeign object, the attributes of the instream foreign object areinterpreted to determine the barcode characteristics, as shown in ablock 176. The characteristics may modify the way in which the barcodesymbol is created. For example, one attribute of the “postnet” typebarcode may be seen at lines 23-24 of the code segment 4 as‘interpretation-line=“none”’ As is known in the art,‘interpretation-line=“none”’ means that no corresponding human readabletext is generated along with the specific barcode symbol. Anotherexample of an attribute associated with the barcode element may be theheight of the barcode symbol, which may also be specified in theinstream foreign object as an attribute.

Using the barcode type and the attributes obtained from the instreamforeign object, the rendering engine 80 then obtains the actual nodetext data to be converted into the barcode symbol, as shown in a block180. In this example, the actual barcode data is the zip code “08540,”as is shown between reverse angled brackets (>80540<) in line 24 of thecode segment 4. The physical conversion from the numerical data “80540”into the bitmap representing the lines or bars of the barcode symbol(for a linear barcode, for example) may be performed by softwareroutines contained in, for example, the barcode label printerscommercially available from Zebra Technologies Corporation. Suchsuitable barcode printers may, for example, be models Xi series barcodeprinters, 90XiIII Plus, 96XiIII Plus, 140XiIII Plus, 170XiIII Plus,220XiIII Plus, the 2800 Series barcode printers, model Z4M, Z6M, 105SLbarcode printers, Model R4Mplus, R402, R-140 printer/encoders, and thelike. Such known software routines or algorithms contained in thebarcode printers commercially available from Zebra TechnologiesCorporation are very efficient, and thus the barcodes are renderedquickly.

For linear barcodes, the bitmap is rendered by converting the text datato a series of dark and light bars whose relative widths conform to theindustry specifications for the barcode symbology. The text data mayhave check characters added before encoding to allow verification of thebarcode when it is read by a barcode scanner. The check characters maybe required or may be optional depending upon the symbology. The barsmay be grouped into modules of bars depending upon the requirements ofthe encoding of the symbology. The text data may be compressed duringencoding depending upon the symbology. The bars may be preceded and/orfollowed by one or more “finder” bars as defined by the symbologyspecifications, which allow a scanner to locate the barcode data moreeasily.

Other algorithms may be applied as needed for the proper encoding andproper physical dimensions required by the symbology. The height of thebars, the width of the narrow bar, the ratio of the wide bar to narrowbar, and other symbology specific parameters may be specified byattributes in the XML data. In addition, the barcode bitmap may berotated (usually in ninety degree increments) as specified by attributesin the XML data.

For two-dimensional barcodes, the bitmap is rendered by converting thetext data to a bit pattern according to the various unique symbologyalgorithms. Two-dimensional barcodes typically allow for encoding ofmore text data than linear barcodes. The encoding algorithm may include,for example, data compression, error checking and correction, varyinglevels of data redundancy, modularization, finder patterns, and otheralgorithms as defined by the symbology. The user-specifiable symbologyspecific parameters may be specified by attributes in the XML data. Thebitmap generated by the symbology algorithm may then be magnified and/orrotated as specified by attributes in the XML data.

Once the bitmap representing the barcode symbol has been generated bythe block 180, that bitmap is then placed into or merged with the“master” or “label” bitmap 184, which label bitmap represents the imageof the entire shipping label, as shown in a block 182. The shippinglabel contains the human readable text, other text or characters, andthe barcode symbol. Note that the aforementioned bitmaps may beseparate, i.e., bitmaps for text and a bitmap for the barcode symbol, orone master bitmap may be used or “populated” as processing progresses.In that regard, note that the tree or data structure upon which therendering engine 80 operates is referred to as the “XSLFO area nodetree,” meaning that it contains different “areas.” Such areas maycorrespond to different or individual bitmaps or bitmap portions.However, any number of suitable bitmap structures may be used. The exactstructure or configuration of the bitmap, or the number of bitmaps isnot relevant to the scope of the present invention.

For example, the XSLFO processor 78 when generating text, may place“its” text in one particular bitmap. Such text may correspond to thename “Albert Einstein” discussed above. Because this text will also beprinted on the shipping label along with the barcode symbol, the“master” or “label” bitmap 184 will contain all of the componentbitmaps. The final “master” bitmap 184 is then sent to the printerdriver 54 (FIG. 1) so that the shipping label may be printed.

Turning now to FIGS. 45, FIG. 5 is a representation 190 of the finaloutput of the above-described processing for the first barcode shippinglabel specified in code segment 1. The text data is rendered andformatted in accordance with the corresponding stylesheet, while the zipcode 192 is also rendered in the form of a barcode symbol by therendering engine 80, as described above. Note that for purposes ofillustration only, the font size or font type shown in FIG. 5 may not bethe same as that specified in the corresponding stylesheet shown in thecode segment 3.

Referring back to block 170, assuming that the instream foreign objecthas the appropriate namespace, if the instream foreign object is not abarcode type, then block 170 interprets the elements in the instreamforeign object to determine if it is an RFID type. Just like any barcodetype may be specified in the instream foreign object, as set forthabove, any RFID transponder type may be specified in the instreamforeign object as well, depending upon the application. The RFIDtransponder type is based upon known RFID standards. For example, theRFID type is not limited to an ISO 15693 type of RFID encoding, and maybe, for example, a Tag-it or I-Code type of RFID encoding, and the like.The RFID type specifies the basic structure of the RFID data to beencoded, such as the data storage capacity, data addressing scheme,transmit frequency, receive frequency, proprietary features such asserial numbering and data locking, and the like. Each specific knownRFID standard is concretely defined, as set forth above.

Next, after it has been determined that the instream foreign object isan RFID type the attributes of the instream foreign object areinterpreted to determine the RFID transponder characteristics, as shownin a block 183. The characteristics may modify the way in which the RFIDtransponder is encoded, such as which block to write, whether towrite-protect (lock) the block, whether to re-try write failures,positioning of the tag under the transceiver antenna during programming,and the like.

Using the RFID transponder type and the attributes obtained from theinstream foreign object, the rendering engine 80 then obtains the actualnode text data to be converted into the RFID transponder encoding, asshown in a block 185. For example, the actual RFID encoding may be thezip code “08540,” which may be placed as ASCII characters in blocks 0and 1 of a Tag-it transponder (since each block of a Tag-it holds 4bytes of data). A Tag-it transponder can hold 8 blocks each with 4 bytesof data for a total of 32 bytes of user data. The physical conversionfrom the numerical data representing the actual RFID encoded data intothe form suitable for encoding into the RFID transponder may beperformed by software routines contained in, for example, the printersand systems commercially available from Zebra Technologies Corporation.

For example, several barcode printer/encoders may be used, such as ModelR-140 and Model R402, and the like. Such software routines or “nativealgorithms” contained in systems commercially available from ZebraTechnologies Corporation are very efficient, and thus the barcodes andRFID transponder encoding are rendered quickly.

Once the RFID transponder encoding has been generated by the block 185,an RFID-specific data structure is rendered, as shown in a block 187.This block renders the RFID-specific data structure to the RFIDtransponder using the native RFID printer algorithms, as describedabove, to control the RFID transceiver 61 (FIG. 1) to read and encodethe RFID transponder 62 (FIG. 2). This essentially “programs” the RFIDtransponder, much in the same way as a programmable memory device isprogrammed.

Referring now to FIG. 6, an alternate embodiment is shown. Likereference numbers are used to denote like structures. In this specificembodiment, the XML system 10 need not include or specifically utilizethe XML printer apparatus in all instances. In this embodiment, forexample, an external requestor 194 may desire to have an XML input datastream rendered into a bitmap so that it can print the barcode label,which may be done remotely. Alternately, the external requestor 194 mayrequest that an RFID transponder be encoded. Accordingly, the externalrequester 194 may send a request to the XML server 200 over the Internetor other network 43, 44. The request may be in the same form as the Xinput data stream described above with respect to FIGS. 1-3 and codesegment-4. The request may also be in the form of a protocol thatcontains XML data, such as SOAP (Simple Object Access Protocol) as isknown in the art.

In response, the computer system 12 of the XML server 200 may processthe XML input data stream. All of the same processing functionsdescribed above are carried out in this embodiment, except that withrespect to barcodes and the like, the bitmap is not sent to the printerdriver. Rather, the bitmap is converted to any suitable format, such as“JPEG” or “PNG” format, as is known in the art. The JPEG or PNG file isthen sent back to the external requestor 194, who then formats the JPEGor PNG file for the appropriate printer driver, and prints and/ordisplays the barcode label. With respect to RFID transponders, theencoded data may be sent back to the requestor in the form of a datafile. Any suitable form or format of data file may be used. Accordingly,the present invention may function as a barcode rendering server and/oran RFID rendering server and need not necessarily directly perform theprinting or encoding functions. Alternatively, the output representationof the data, may be in Scalable Vector Graphic format (SVG), whichformat is defined by appropriate industry standards.

An alternate embodiment of the XML system of FIG. 1 is now shown inFIGS. 7-8, which show a “hybrid” XML system 300, rather than the“native” XML system 10 shown in FIGS. 2-6. Note that this embodiment maystill be used with the computer system 12 and printer system 50 shown inFIG. 1, and like reference numerals will be used to denote likestructure or components.

In this embodiment, the hybrid XML printer system 300 may receive XMLdata that is based on ZPL data templates, which templates conform to theZPL language (Zebra Programming Language), such as ZPL I and/or ZPL II,and any variants thereof. The ZPL language is a formatting language thatuses the “caret” character and a two-letter command code to define acommand. For example, the “^XA” command defines the start of a new labelformat, and the “^XZ” command defines the end of a label format.

The ZPL language also includes “tilde” commands, which represent controlcommands. For example, the command “˜JR” is a printer reset command,which is acted upon immediately by the printer, and does not really havesignificant bearing on the actual formatting of a barcode label. ZPL Iand ZPL II were developed by Zebra Technologies Corporation of VernonHills, Ill., the owner of the present invention. Note that ZPL is usedinterchangeably with ZPL II herein.

Greater detail regarding the ZPL language specification can be found indocuments entitled “ZPL II Programming Guide Volume One: CommandReference for X.10,” Manufacturer Part No. 45541LB, and “ZPL IIProgramming Guide Volume Two: The X.10 Environment,” Manufacturer PartNo. 45542LB, which documents may be found and downloaded at the ZebraTechnologies Corporation website at the following Internet web address“www.zebra.com/SS/manuals.htm.” The aforementioned documents are herebyincorporated by reference in their entirety. In the embodiment of FIGS.7-9, the “language” of the printer system is a hybrid of both ZPL andXML, thus the XML system 10 may be referred to as a “hybrid XMLprinter.”

As is known, ZPL-based printers can handle “on demand printing” and“stored label format.” On-demand printing means that when a data streamcontaining label data to be printed is sent to the printer, it isimmediately printed. Stored label format means that templates for thelabels may be created in advance and downloaded to the printer. Thetemplates may then be recalled internally within the printer to use inconjunction with a data stream transmitted at a later time that containsthe label data to be printed.

As will become more clear in the description below, one differencebetween the native XML printer system embodiment of FIGS. 2-6 and thehybrid XML printer system embodiment of FIGS. 7-8 is that in the hybridXML printer system embodiment, the data templates are predefined in ZPLand are first downloaded to the printer. Also note that the hybridembodiment of FIGS. 7-8 is not a combination of the native kML printersystem of the embodiment of FIGS. 2-6 with a known ZPL printer. It isnot a “two-in-one” printer that merely switches between a native XMLmode and a ZPL mode.

The hybrid XML printer system of FIGS. 7-8 is different from the nativeXML printer system of FIGS. 2-6 in which XSLT is used to define andlayout the label in conjunction with XSL formatting elements embedded inthe XSL template. To handle the layout and formatting of a label in theembodiment of the native XML printer system of FIGS. 2-6, a company (orvendor) must prepare and define a label layout using XSL formattingobjects, and in many situations, must also prepare XSL stylesheets andXSL schema, as set forth above in the native XML printer embodiment. Ifthe business entity's ERP system 88 was able to transmit well-formed XMLdata using XSL formatting objects and the like (i.e., XSL style sheetsand schema) in the first place, then there would be no need to use theZPL templates, which would indicate that the business entity alreadymade the complete switch to a fully compatible XML ERP system, thusobviating the need for any form of ZPL.

Some companies, however, may not be ready or willing to make theinvestment to such a “full conversion” of its system into “pure XML”because such companies may have a sizeable investment in the older ZPLtemplates for their labels to be printed. Many companies are buildinginfrastructure to permit AL data to be easily passed from businessprocess to business process because transmission of such data in XMLcompatible format is becoming the industry standard. Although manycompanies, and the industry as a whole, are moving in the direction ofusing XML format for data, such companies may not want to scrap theirinvestment in their template database infrastructure just to make theswitch to a fully compatible X format.

Accordingly, the hybrid XML printer embodiment of FIGS. 7-8 permits useof existing ZPL templates with data in XML format. The ERP system 88 maycontinue to use the existing ZPL templates because the “complete” switchto well-formed XML has not yet been made, most likely for economicreasons. Thus, XSL stylesheets, schema and formatting objects have notyet been implemented at the ERP site, and the hybrid XML printer systemprovides a cost-effective solution in such environments.

Turning now to FIG. 7 and code segment 5, the code segment shownimmediately below entitled “code segment 5 —a ZPL downloadable template”shows a specific example of a ZPL format template that may betransmitted to the hybrid XML printer system 300 prior to the printingof an actual bar code label, and which may be saved in the memory of theprinter system for future printing jobs. Line numbering has beeninserted for purposes of illustration only and is not part of the code.

Code Segment 5 - a ZPL downloadable template {circumflex over ( )}XA  {circumflex over ( )}DFE:SHIPLABL.ZPL{circumflex over ( )}FS  {circumflex over ( )}MCY   {circumflex over ( )}LRN{circumflex over( )}FWN{circumflex over ( )}CFD,24{circumflex over ( )}LH0,0 {circumflexover ( )}CI0{circumflex over ( )}PR2{circumflex over ( )}MNY{circumflexover ( )}MTT{circumflex over ( )}MMT{circumflex over ( )}MD0{circumflexover ( )}JJ0,0{circumflex over ( )}PON{circumflex over ( )}PMN  {circumflex over ( )}LT0   {circumflex over ( )}A0N,58,58{circumflexover ( )}FO188,169{circumflex over ( )}CI0{circumflex over( )}FN999{circumflex over ( )}FDname{circumflex over ( )}FS  {circumflex over ( )}A0N,58,58{circumflex over( )}FO188,244{circumflex over ( )}CI0{circumflex over( )}FN998{circumflex over ( )}FDaddress{circumflex over ( )}FS  {circumflex over ( )}A0N,58,58{circumflex over( )}FO188,319{circumflex over ( )}CI0{circumflex over( )}FN997{circumflex over ( )}FDcity{circumflex over ( )}FS {circumflexover ( )}A0N,58,58{circumflex over ( )}FO657,319{circumflex over( )}CI0{circumflex over ( )}FN996{circumflex over ( )}FDstate{circumflexover ( )}FS   {circumflex over ( )}A0N,58,58{circumflex over( )}FO188,394{circumflex over ( )}CI0{circumflex over( )}FN995{circumflex over ( )}FDzip{circumflex over ( )}FS   {circumflexover ( )}BY4{circumflex over ( )}FO188,488{circumflex over( )}BZN,35,N{circumflex over ( )}FN995{circumflex over( )}FDzip{circumflex over ( )}FS   {circumflex over ( )}PQ1,0,1,Y{circumflex over ( )}XZ

As is known in the art, the commands shown at lines 1 and 14 (^XA, ^XZ)define the beginning and end of the template, as is specified in the ZPLlanguage. Line 2 indicates that the format template downloaded to thehybrid printer system 300 is stored in the memory of the hybrid printerat a location defined by “E:SHIPLABL.ZPL,” where “E:” represents astorage device identifier, which may be, for example, a disk drive.However, any suitable storage device may be used. The inclusion of thiscommand indicates that this format template is to be saved. Lines 3-6represent some of the various printer setup and initialization commandsprovided for by the ZPL programming language.

Referring now to line 7, the “^A0” command with an associated parameterof “N” means that a text field is to be created using font number zero,and in a normal (“N”) orientation (i.e., the font is not rotated), where“58, 58” represents the height and width (in dots) of the text that willbe printed. As provided for in the ZPL language, the command “^FO188,169” defines the field origin so that the text will be positioned atcoordinates 188, 169 (i.e., 188 dots across and 169 dots down from thebeginning of the label).

The field number command “^FN999” (FN command with the parameter of“999”) defines a variable field, which will contain variable informationto be downloaded to the printer at a later time. In that regard, this issomewhat different than in standard ZPL. In standard ZPL, when an “^FN”command in a template is received, no data is supplied along with thecommand because when the template is later recalled, a subsequent “^FN”command is sent that specifies the location of that variable data,followed by the data itself. In this hybrid embodiment, however, certain“association” data is provided immediately following the “^FN” command,as indicated by the “^FD” field data command. In this specific example,the data immediately following the “^FN” command, but preceded by the“^FD” field data command, is shown as “name,” which is the data thatwill be matched with the XML data sent from the ERP or warehouse systemat a later time. Thus, when the template shown in code segment 5 isreceived by the hybrid XML printer system 300, it is stored in memory ofthe printer, and additionally, the “association” between “name” andfield “999” is stored.

Similarly, on line 8, the association between “address” and field 998 isstored, on line 9 , the association between “city” and field 997 isstored, and so on. Note that the fields represented by, for example,“name,” “address,” “city,” and the like, are not the actual data to besent as XML data by the ERP system 88. Rather, “name,” “address,” and“city” are “tags” or “associations” that associate the data that willlater be sent by the ERP system with the field location or identifier,namely, “999,” “998,” and “997,” respectively.

Turning now to line 12, the “^BY” command defines default parameters forbarcode commands which follow it. In this case the parameter of 4defines the narrow bar width to be 4 dots. The “^FO” command definesthat the barcode to be printed will be placed at coordinates 188, 488.The “^BZ” command defines a barcode, which is a postnet type of barcodeformat, with normal orientation (parameter of N), height of 35 dots(parameter of 35), and no human-readable interpretation line (parameterof N). Further, the “FN” command with a parameter of 995 specifies theassociation between the label field identified as “995” with name of theXML data to be downloaded, which is defined by the data command “^FD”having an attribute of “zip,” which further specifies that “zip” is thename of the XML data to be downloaded to create the actual printedbarcode. The actual barcode that is printed is the zip code 304, asshown in FIG. 9.

Of course, text fields are printed on the barcode label 305 as well asthe barcode itself 304, as shown in FIG. 9. Such fields, may include forexample, a name 306, address 308, city 310, state 312, and text zip code314.

Thus, in this embodiment, the template shown in code segment 5 is storedin the hybrid XML printer system 300, and no real “work” is performed(i.e., a label is not yet printed). In summary, lines 7-11 define textfields and line 12 defines a bar code that are defined along withassociations that will be correlated with actual XML data sent from theERP system 88 at a later time, along with other parameters, as set forthabove. The template of code segment 5 may define which fields are staticand which fields are variable. The variable fields have a variable name(stored in the ^FD command), which may be later correlated or“associated” with data to be downloaded at a later time, which datacorresponds to the printed label.

Thus, in the hybrid embodiment of FIGS. 7-8, the “^FD” command (i.e.,followed by “name”) determines the name of the variable that will besent in the actual XML data that eventually follows the downloading ofthe template, rather than the actual data that will be printed on thebarcode label.

To see how the format template of code segment 5 above is used inoperation, code segment 6 is shown immediately below, and is entitled“code segment 6 —downloaded XML data for use with a ZPL template.” Linenumbering has been inserted for purposes of illustration only and is notpart of the code.

Code Segment 6 - downloaded XML data for use with a ZPL template <?xmlversion=“1.0” encoding=“UTF-8”?>  <!DOCTYPE labels SYSTEM “label.dtd”> <labels _FORMAT=“E:SHIPLABL.ZPL” _QUANTITY=“1”  _PRINTERNAME=“Printer1” _JOBNAME=“LBL101”>  <label>    <variable name=“name”>AlbertEinstein</variable>   <variable name=“address”>1234 RelativeWay</variable>   <variable name=“city”>Princeton</variable>    <variablename=“state”>NJ</variable>   <variable name=“zip”>08540</variable>  </label>  <label>   <variable name=“name”>Steven Hawking</variable>   <variable name=“address”>5678 Black Hole Drive</variable>   <variablename=“city”>Los Angeles</variable>   <variablename=“state”>CA</variable>    <variable name=“zip”>90007</variable> </label>   <label>   <variable name=“name”>Richard Feynman</variable>  <variable name=“address”>90 Quantum Circle</variable>    <variablename=“city”>New York</variable>   <variable name=“state”>NY</variable>  <variable name=“zip”>10044</variable>  </label>  </labels>

Code segment 6 represents the actual XML data stream that the ERP system88 or warehouse management system would send to the hybrid XML printersystem 300, but after the format template of code segment 5 was firstdownloaded to the hybrid XML printer system. In the specific example ofcode segments 5 and 6, the warehouse management system that may be used,for example, is an Oracle warehouse management system (the “Oraclesystem” or “Oracle WMS”). Of course, any business system may be used,such as Oracle, SAP, and the like. In this specific example, the Oraclesystem gathers data from its database and formats the data in aparticular XML format for transmission to the printer. Because thisspecific example uses the Oracle system, the template of code segment 6uses Oracle XML semantics.

In that regard, the particular AL semantics used by the Oracle warehousemanagement system is defined in line 2 of code segment 6 by the “DTD” ordocument type definition, which is identified as “label.dtd,” as isknown in the art. Also, as is known in the art, the ERP system 88 orOracle system has the capability of specifying the format in which theXML data is to be printed. By way of background, this capability mayhave been originally built into the Oracle system and other ERP systemsbecause such systems were designed to interface to a custom “middleware”software system, which handled the format conversion between the Oracleor ERP system and the particular barcode printer in use. The presenthybrid printer eliminates the need for such a “middleware” system.

However, the XML data transmitted by the Oracle system specifies on line3 of code segment 6 that there is an AL element called “labels,” whichhas an attribute called “_FORMAT.” This attribute specifies theparticular format template to use. In this specific example, the formattemplate to use with the transmitted XML data is identified as“E:SHIPLABL.ZPL,” which is the format template previously stored in thehybrid XML printer system 300, as shown in code segment 5, and which isa ZPL based format template. Thus, the format template previouslydownloaded and stored in the memory of the hybrid XML printer system 300may be recalled from a location specified by “E:SHIPLABL.ZPL.”

Line 3 also contains some additional attributes of the “labels” element,such as “_QUANTITY,” “_PRINTERNAME,” and “_JOBNAME.” The attribute“_QUANTITY,” specifies the number of barcode labels to print, while theattributes “_PRINTERNAME,” and “_JOBNAME” are legacy fields not neededby the hybrid XML printer system 300, but are nonetheless included inthe Oracle data because such data was originally created to interface tothe middleware software, as described above.

The code segment 6 contains three groups of “label” data, as shown atlines 5-11, 12-18, and 19-25, respectively. Note that the three groupsof “label” data appear to be similar to code segment 1, namely lines8-14, 15-21, and 22-28 respectively, because both code segments refer to“Albert Einstein,” “Steven Hawking,” and “Richard Feynman,”respectively, and have associated fields for address, city, state, andzip code data. Accordingly, the data shown in code segment 6 correspondsto three individual labels to be printed. Note, however, that for eachof the three labels to be printed, all of the addressee information isprinted as text, but only the zip code field is printed as an actualbarcode. This is because of the “^BZ” command defined in template ofcode segment 5, line 12.

Referring to code segments 5 and 6, the data transmitted by the Oraclesystem shown in code segment 6 is then associated with the correspondingformat template shown in code segment 5. For example, in line 6 of codesegment 6, the variable name of “name” corresponds to “Albert Einstein,”which is the actual XML text data. Using the previously saved templateof code segment 5, an association is made between “name” (the contentsof which are “Albert Einstein”) and the field number “999,” as shown inline 7 of code segment 5. The XML data “Albert Einstein” is then savedin memory defined by the field number 999.

Similarly, the XML data “1234 Relative Way” is saved in memory definedby the field number 998, the XML data “Princeton” is saved in memorydefined by the field number 997, the XML data “NJ” is saved in memorydefined by the field number 996, and so on. Once all of the datacontained in the XML data input stream have been associated with thecorresponding template and have been loaded into memory, the label isprinted.

Turning now to FIGS. 7 and 8, FIG. 7 shows a high-level functional blockdiagram of a specific embodiment of the hybrid XML printer system 300,while FIG. 8 illustrates a combined high-level software block diagramand data flow diagram of a specific embodiment of the hybrid XML printersystem. The hybrid XML printer system 300 receives data from theenterprise resource planning (ERP) system 88, as described above withrespect to the native XML printer system. The data may contain both XMLcomponents and ZPL components, such as XML data and/or the ZPL templatedata.

The high level blocks of FIG. 7 illustrate use of a SAX processor 320,which is a type of XML processor. By way of background, a SAX processor(Simple API for XML) does not use the DOM processing model (DocumentObject Model) used by the XML processors described above with respect tothe native XML printer system of FIGS. 2-6.

As described above, DOM-based XML processors create a node tree inmemory in order to carry out its processing steps, as is known in theart. This is necessary when performing XSL type processing, as describedabove with respect to the embodiment of FIGS. 2-6. Accordingly, all datais stored in memory, and thus may occupy a large amount of memory. A SAXprocessor, however, interprets XML syntax and data streams, and ratherthan building a node tree in memory, it creates “events” that arehandled by event handlers, as is known in the art. SAX processors arevery memory efficient, which is desirable when processing large amountsof XML data.

In this alternate embodiment of FIGS. 7-8, however, XSL-type processingis preferably not performed, hence processing based on node trees inmemory is not required. Accordingly, rather than using an XML processorthat is strictly DOM-based, a SAX processor may be used, as shown inFIG. 7. The term “SAX” merely refers to a specification regarding how tohandle data and syntax of the XML language. For example, a commerciallyavailable XML processor that may be used in this embodiment is the“Expat” XML processor available from Thai Open Source Software Center,Ltd. Although this specific model of XML processor has the capability tofunction as both a DOM-based XML processor or a non DOM-based SAXprocessor, for purposes of this embodiment, the processor is preferablyconfigured as a non-DOM-based XML processor, and thus will be referredto as the SAX processor. However, any suitable DOM-based or nonDOM-based XML processor may be used.

As shown in FIG. 7, in addition to the SAX processor 320, a ZPLprocessor 322 is also shown. The data paths from the SAX processor 320and the ZPL processor 322 are then routed to the block labeled VariableData Integration 328. The Variable Data Integration block 328 combinesthe XML data received from the ERP system 88 and applies or “associates”the data with the fields that were previously defined by the ZPLtemplate, as mentioned above with respect to the ZPL template of codesegment 5. Essentially, in this step, the actual XML data, for example,the name “Albert Einstein,” is saved in its associated location definedby 999 of the template of the code segment 5, and the like.

Next, the data is rendered by a Bitmap/Barcode/RFID Rendering block 330,which processing is similar to known ZPL bitmap rendering used in knowncommercially available ZPL printers. For example, the following knownZPL printers, which are commercially available from Zebra TechnologiesCorporation of Vernon Hills, Ill., may include software, hardware,and/or firmware able to perform the ZPL bitmap/barcode processing asfollows: Zebra Models XiIII+, 90XiIII+, 96XiIII+, 110XiIII+, 140XiIII+,170XiIII+, 220XiIII+, Model Z4M, Z6M, 105SL Model R4Mplus, R402, R-140printer/encoders, and any Model Xi series barcode printers from ZebraTechnologies Corporation. Note that the Bitmap/Barcode/RFID Renderingblock 330 is preferably performed without use of any XSLFO processing,which processing was required in the native XML printer systemembodiment, and no XSLT stylesheets or schema may be used. However, XSLTprocessing and schema handling are contemplated and are within the scopeand spirit of the subject invention.

Additionally, the RFD transceiver 61 may be operatively coupled to theBitmap/Barcode/RFID Rendering block 330 to facilitate communication withthe RFID transponder 62. The RFID transceiver 61 and transponder 62 maybe similar to or the same as the transceiver and transponder shown anddescribed above with respect to the embodiments of FIGS. 1, 2 and 6.

The barcodes are rendered as described above for the native XML printerembodiment, but preferably with the exception that the barcodeparameters are not specified in the XML data as attributes, but rather,are preferably specified by ZPL command parameters in the formattemplate. For example, the ZPL command “^BY2,2,100” specifies, for alinear barcode, that the narrow bar width will be 2 dots, the ratio ofthe wide bar width to narrow bar width will be 2, and the height of thebars will be 100 dots. After the bitmap is rendered, it is routed to theprinter driver 54, which is also shown in FIG. 1. The printer driver 54is an example of a component described above whose function may beperformed by either the processing device in the computer system 12 orthe processing device 60 (FIG. 1), depending upon the physical locationof the associated processing device. Again, a single processing device,if sufficiently powerful, may handle all functions for the hybrid XMLprinter system 300.

Referring now to FIGS. 1, 7 and 8, FIG. 8 illustrates a specificembodiment of a combined high-level software block diagram and data flowdiagram. The software described below may be executed by the processor28 of the computer system 12 of FIG. 1. Again, the processor 28 mayperform functions common to both the computer system 12 and the printersystem 50. There may be one or more processors, which may function inconcert or which may function separately. It is not material to thescope of this invention whether the processing or processing functionsare performed by or in the computer system or by or in the printersystem.

As will be described below, multiple “passes” through the processingsteps shown in FIG. 8 may occur under control of the SAX processor 320.However, such multiple “passes” are not necessarily linear and thus, anexact path shown by specific lines or arrows in FIG. 8 may notnecessarily be shown. An interative process is described that may nothave an exact beginning and ending point shown on FIG. 8. Rather, anaction or result generated by the pass may be shown, and thus an“alternative path” may be shown in FIG. 8 in dashed lines that returnsprocessing control back to the SAX processor 320. This is a shorthandway of indicating that the path may be iterative and that the SAXprocessor 320 may loop or iterate many times before processing reachesits end.

For purposes of illustration only, in a first “pass” through theprocessing illustrated in FIG. 8, a ZPL template is first sent to thehybrid XML printer system 300, where the actual data to be printed isnot yet sent. In a second “pass,” as will also be described below, theXML data representing the barcode label to be printed is sent to theprinter system, to be printed in accordance with the ZPL templatepreviously saved.

As shown in FIG. 8, a data input stream 340 is received from the ERPsystem 88, and as described above, may contain XML data and/or ZPLtemplate data. The SAX processing block 320 initially receives andparses the data input stream 340. Note that the SAX processing block 320is actually performed by an XML processor because a SAX processor is anXML processor operating in a SAX mode. Thus, the phrase XML processor orXML processing block may be interchanged with the phrase SAX processoror SAX processing block. However, as described above, the XML processorpreferably operates in SAX mode, and is thus referred to as the SAXprocessor 320.

First, the SAX processing block 320 determines whether the data inputstream 340 is well-formed XML data by applying standard XML syntax rulesto the data input stream. Note that the SAX processing block 320 of FIG.8 is essentially the same as the SAX processor of FIG. 7 with FIG. 7showing some hardware and FIG. 8 showing data flow. The terms SAXprocessor and SAX processing block will be used interchangeably herein.

If the SAX processing block 320 determines that the data input streamdoes not conform to XML syntax, then it is assumed that the data inputstream is ZPL based. Accordingly, the SAX processing block 320 routesthe data input stream 340 to the ZPL processing block 322 for furtherprocessing. Note that the ZPL processing block 322 of FIG. 8 isessentially the same as the ZPL processor of FIG. 7 with FIG. 7 showingsome hardware and FIG. 8 showing data flow. The terms ZPL processor andZPL processing block will be used interchangeably herein.

The ZPL processing block 322 then processes or parses the data inputstream 340, which represents the ZPL format template. Preferably, theZPL processing block 322 receives a “beginning of label” command (^XA),which causes it to begin processing the format template. The formattemplate is shown in the code segment 5.

Various ZPL commands govern the processing and define the fields of thelabel, essentially establishing and defining the data to be printed.Printer control and other commands may be received at this stage ofprocessing. When all of the format template has been downloaded, the ZPLprocessing block 322 encounters an “end of label” command (As, whichcauses the format template to be saved. Note that the ^DF command withthe corresponding identifier “E:SHIPLABL.ZPL,” (shown at line 2 of codesegment) indicates to the ZPL processing block 322 that the formattemplate is preferably saved internally in the printer system on the“E:” device in a file named “shiplabl.zpl.” Of course, the formattemplate need not be saved internally in the printer system and may besaved at any storage location, such as on a networked server or a remotelocation accessible through a communication network.

The ^DF (Download Format) ZPL command indicates that the label format ofwhich it is part is to be stored rather than immediately printed. Thesave actually takes place when the ^XZ is encountered which indicatesthat all template data has been received.

Also note in FIG. 8, a block labeled “ZPL label formats” (352)represents a data store. This indicates that the template data comingfrom the input stream is stored in a data store. The line exiting thedata store 352 indicates that at some later time the data is retrievedfrom the data store for additional processing. The data flow path isfrom the block 360 to the store to the block 356, but this does notrepresent the actual “control flow,” which is not a linear flow.

Although a block labeled “recall ZPL label format” 356 is shownconnected to the block labeled “save ZPL label format” 360 as mentionedabove, processing may not be linear, and thus data flow may notnecessarily continue or flow from the “save ZPL label format” block 360to the “recall ZPL label format” block 356. Rather, the entire processis iterative as described above, and in this initial “pass,” after theZPL label format is saved, as shown in the block 360, control of theinput data stream may revert back to the SAX processing block 320 forcontinued processing, as shown by dashed lines 370. If there is noadditional data in the data input stream 340 to be processed, processingterminates and awaits additional downloaded data.

In a second “pass” through the processing illustrated in FIGS. 7-8, theERP system 88 may transmit the actual XML data, which will be processedby the hybrid XML printer system 300 in accordance with the previouslydownloaded ZPL template. For example, the SAX processing block 320 mayreceive well-formed XML data, which may specify that label data is tofollow. To process the actual data, the stored ZPL format is recalled,as shown in the block labeled “recall ZPL label format” 356, so that therecalled format template may be used in conjunction with the incomingXML data stream.

The SAX processing block 320 processes the XML syntax and determinesvarious elements and attributes defined by the data input stream 340. Inthis embodiment upon receiving a “_FORMAT” attribute, the data inputstream 340 is temporarily interrupted and input data comes from theformat template stored in the printer system 300, and thus the ZPLcommands embedded in the format template are interpreted by the ZPLprocessing block 322. Once the commands in the format template have beeninterpreted, the data input stream 340 again becomes the SAX processingblock 320, which continues to process the XML data.

Additional passes through the processing under control of the SAXprocessor 320 may cause various “events” to be initiated, as describedabove. For example, a “variable data SAX event” 376 may be initiated sothat the various fields in the format template are populated with thecorresponding or “associated” XML data being received. This is shown bythe block labeled “Match XML variable with ZPL label format variable”380. Essentially, the variables in the XML data input stream 340 areassociated with the fields in the format template. For example, in thisstep, the XML variable, such as the actual XML data “Albert Einstein”(306 of FIG. 9) shown in code segment 6, is matched with the ZPL labelformat variable, such as the label variable “name” in the ZPL templateof code segment 5.

The SAX processor 320 may initiate further events to handle the tasksdescribed above, such as a “begin label SAX event” 384, and “other SAXevents” 388. This pass or other passes through the processing of FIG. 8under control of the SAX processor 320 may cause the generation of“other SAX events,” which may be processed by a block labeled “processevent” 390. For example, such “other” events may include “set printerspeed event,” “set quantity of labels to print event,” “select mediaevent,” “select ribbon to use event,” “choose paper event,” “use 300 dpiprinter event,” “use 600 dpi printer event,” “variable data event,” andthe like.

The number of such events are virtually unlimited, and are governed bythe type, configuration, and capability of the hardware printer system.Essentially, all aspects and functions of the printer may be controlledby use of codes sent in the data input steam 340. This also allows theprinter to determine if it is capable or configured to print the labeldescribed by the XML data stream, and to optionally return errorinformation if it cannot. Although in code segment 6 corresponding tothe Oracle-base XML data, only a limited number of “other commands” areshown (namely, quantity=1 and printer name=printer 1, both shown on line3), essentially, any function or feature that may be controlled in theprinter may be specified in the XML input data stream, as mentionedabove. Thus, there may be a close binding between the actual XML inputdata and printer control codes.

Also note that such “other” commands and corresponding “other events”generated by the SAX processing block 320 in response to the commandsare not part of or specific to the Oracle system, meaning that theOracle system does not necessarily “know” what these commands do or howthey are used. It is only when such downloaded commands are matchedduring SAX processing that the commands and subsequent generated eventstake on meaning.

When an “end of label element” event (</label>) is received, the labelis complete and now may be printed. Control is then routed to a ZPLformatting engine processing 394, which causes the label to be printed.Preferably, the function of the ZPL formatting engine processing 394includes the function of bitmap/barcode/RFID rendering. Thus, the block394 will be referred to as the ZPL formatting engine. This combinedfunction determines the bitmaps for each of the text, barcode, and otherfields on the label, integrates the individual bitmaps with properrotation and magnification into a single label bitmap 396, and sends thecompleted label bitmap to the print engine (or printer driver 54,FIG. 1) for physical rendering on media. As described above, the ZPLformatting engine processing 394 may be found in various commerciallyavailable ZPL printers, such as for example, in printers commerciallyavailable from Zebra Technologies Corporation of Vernon Hills, Ill.,which may include the following printer models: XiIII+, 90XiIII+,96XiIII+, 110XIII+, 140XiIII+, 170XiIII+, 220XiIII+, Model Z4M, Z6M,105SL Model R4Mplus, R402, R-140 printer/encoders, and any Model Xiseries barcode printers.

The ZPL formatting engine processing 394 essentially determines all ofthe fields contained in the label to be printed and determines what mustbe done for each field. For example, the ZPL formatting engineprocessing 394 may determine that the field containing the data “AlbertEinstein” (306 of FIG. 9) shown in line 6 of code segment 6 is printedusing font number zero and in a normal (“N”) orientation, and is 58 dotsin height and 58 dots in width, and begins at a field origin coordinateof 188, 169, as indicated by line 7 of the code segment 5.

Thus, the ZPL formatting engine processing 394 inspects all of thefields defined by the format template in conjunction with thecorresponding XML data and essentially determines how to create dots (orbits) on the label that represent the text or barcode. Barcode fieldsare formatted and rendered by applying the appropriate bitmap generationalgorithm to the field parameters based upon the barcode symbologyspecified for the field accounting for horizontal and vertical sizing oflinear barcodes and magnification of two-dimensional barcodes.

Also, the RFID transceiver 61 may be operatively coupled to the ZPLformatting engine processing 394 to facilitate communication with theRFID transponder 62. The RFD transceiver 61 and transponder 62 may besimilar to or the same as the transceiver and transponder shown anddescribed above with respect to the embodiments of FIGS. 1, 2, 6 and 7.

Turning now to code segment 7, the code segment shown immediately belowentitled “code segment 7 —a ZPL downloadable template with RFID and datalogging commands” shows code segment 5 with certain RFID and datalogging commands added. The added code will cause reads from and writesto the RFID tag, and logging of the RFID data to a host computer. Linenumbering has been inserted for purposes of illustration only and is notpart of the code.

Code Segment 7 - a ZPL downloadable template with RFID and data loggingcommands {circumflex over ( )}XA   {circumflex over( )}DFE:SHIPLABL.ZPL{circumflex over ( )}FS   {circumflex over( )}LXE:LOG04128.XML{circumflex over ( )}FS   {circumflex over ( )}MCY{circumflex over ( )}LRN{circumflex over ( )}FWN{circumflex over( )}CFD,24{circumflex over ( )}LH0,0   {circumflex over( )}CI0{circumflex over ( )}PR2{circumflex over ( )}MNY{circumflex over( )}MTT{circumflex over ( )}MMT{circumflex over ( )}MD0{circumflex over( )}JJ0,0{circumflex over ( )}PON{circumflex over ( )}PMN   {circumflexover ( )}LT0   {circumflex over ( )}A0N,58,58{circumflex over( )}FO188,169{circumflex over ( )}CI0{circumflex over( )}FN999{circumflex over ( )}FDname{circumflex over ( )}LX{circumflexover ( )}FS   {circumflex over ( )}A0N,58,58{circumflex over( )}FO188,244{circumflex over ( )}CI0{circumflex over( )}FN998{circumflex over ( )}FDaddress{circumflex over( )}LX{circumflex over ( )}FS {circumflex over ( )}A0N,58,58{circumflexover ( )}FO188,319{circumflex over ( )}CI0{circumflex over( )}FN997{circumflex over ( )}FDcity{circumflex over ( )}LX{circumflexover ( )}FS   {circumflex over ( )}A0N,58,58{circumflex over( )}FO657,319{circumflex over ( )}CI0{circumflex over( )}FN996{circumflex over ( )}FDstate{circumflex over ( )}LX{circumflexover ( )}FS   {circumflex over ( )}A0N,58,58{circumflex over( )}FO188,394{circumflex over ( )}CI0{circumflex over( )}FN995{circumflex over ( )}FDzip{circumflex over ( )}LX{circumflexover ( )}FS   {circumflex over ( )}BY4{circumflex over( )}FO188,488{circumflex over ( )}BZN,35,N{circumflex over( )}FN995{circumflex over ( )}FDzip{circumflex over ( )}FS   {circumflexover ( )}WT{circumflex over ( )}FN995{circumflex over( )}FDzip{circumflex over ( )}FS {circumflex over( )}A0N,58,58{circumflex over ( )}FO188,394{circumflex over( )}CI0{circumflex over ( )}FN994{circumflex over ( )}FDtagid{circumflexover ( )}FS   {circumflex over ( )}RI{circumflex over( )}FN994{circumflex over ( )}FDtagid{circumflex over ( )}LX{circumflexover ( )}FS   {circumflex over ( )}PQ1,0,1,Y {circumflex over ( )}XZ

The inclusion of the write tag (^WT) command on line 14 indicates thatthe data specified by field number 995, indicated by the ^FN fieldnumber command with a parameter of 995, is to be written to (encoded on)the RFID tag. In this example the XML data associated with field number995 is the zip code. The actual zip code data, “08540” for the firstlabel, will be encoded on the RFID tag.

The inclusion of the read unique tag id (ARI) command on line 16indicates that the tag id number is to be read from the tag andassociated with an XML variable named “tagid,” as specified by the ^FDwith a parameter of “tagid” on line 16. In addition, the data read fromthe tag is associated with field number 994 (^FN command with aparameter of 994). Since the text field on line 15 also has a fieldnumber of 994, the tag id which is read from the RFD tag will be printedas text on the label in location 188, 394.

The inclusion of a new ZPL command, “log in XML” (^LX), on lines 3, 8,9, 10, 11, 12, and 16 indicates that certain field data should be savedin a data log for later transmittal to a host computer. The^LXE:LOG04128.XML command on line 3 indicates that log data for thislabel should be saved in a file on the E: device in a file called“LOG04128.XML.” The ^LX commands on lines 8, 9, 10, 11, 12, and 16indicate that the data associated with those fields should be saved inthe log with the previously specified name. For example, when the ^LXcommand on line 8 is processed, the data associated with the “name”field will be logged. The actual data to be logged for the first labelis “Albert Einstein” as shown on line 6 of code segment 6. The datalogged for the ^LX on line 16 is the unique tag id read from the tag.For the purposes of this example, assume that for the first label theunique tag id read from the tag is “1248002001.”

To see how the data indicated in the format template of code segment 7above is returned to a host computer, code segment 8 is shownimmediately below, and is entitled “code segment 8 —uploaded XML data.”Line numbering has been inserted for purposes of illustration only andis not part of the code.

Code Segment 8 - uploaded XML data <?xml version=“1.0”encoding=“UTF-8”?> <root _LOGFILE=“E:LOG04128.XML”>  <labels_FORMAT=“E:SHIPLABL.ZPL” _QUANTITY=“1”>   <label>    <variablename=“name”>Albert Einstein</variable>    <variable name=“address”>1234Relative Way</variable>    <variable name=“city”>Princeton</variable>   <variable name=“state”>NJ</variable>    <variablename=“zip”>08540</variable>    <variablename=“tagid”>1248002001</variable>   </label>   <label>    <variablename=“name”>Steven Hawking</variable>    <variable name=“address”>5678Black Hole Drive</variable>    <variable name=“city”>LosAngeles</variable>    <variable name=“state”>CA</variable>    <variablename=“zip”>90007</variable>    <variablename=“tagid”>1248002002</variable>   </label>   <label>    <variablename=“name”>Richard Feynman</variable>    <variable name=“address”>90Quantum Circle</variable>    <variable name=“city”>New York</variable>   <variable name=“state”>NY</variable>    <variablename=“zip”>10044</variable>    <variablename=“tagid”>1248002003</variable>   </label>  </labels> </root>

When the printer is requested to upload the log data, the printer formsan XML data stream similar to that shown in code segment 8. The data isvery similar to the AL data sent to the printer in order to print thelabels, but with some additions. A “root” element has been added so thatdata from more than one complete print job can be returned in the sameXML stream. The name of the log file is specified in the _LOGFILEattribute shown on line 2. The data that was read from the RFID tag isincluded as “tagid” variables on lines , , and 26. When this data isreceived by a host computer, the host will know that the RFID tag withid of “1248002001” was used to identify the goods shipped to AlbertEinstein. This data can be stored in a database on the host computer forlater reference. Although this example is shown with the unique tagidentifier, any data written to or read from the RFID tag could bereported to the host computer in a similar manner.

The hybrid printer system is not limited to the use of ZPL for theprinter control and label template language. Other proprietary ornon-proprietary printer control languages (PCLs) besides ZPL could beused in a similar manner as long as XML can be differentiated from thePCL.

Specific embodiments of an XML system, including a native XML printersystem and a hybrid XML printer system, according to the presentinvention have been described for the purpose of illustrating the mannerin which the invention may be made and used. It should be understoodthat implementation of other variations and modifications of theinvention and its various aspects will be apparent to those skilled inthe art, and that the invention is not limited by the specificembodiments described. It is therefore contemplated to cover by thepresent invention any and all modifications, variations, or equivalentsthat fall within the true spirit and scope of the basic underlyingprinciples disclosed and claimed herein.

1. An XML system for printing bar code labels, tags, tickets, cards orother media and/or for encoding of RFID devices embedded in the media,based upon an Extensible Markup Language (XML) input data stream and aformat template, the XML system comprising: a computer system having amemory subsystem; a communication interface operatively coupled to anetwork; an XML processor configured to receive and process the XMLinput data stream; a Zebra Programming Language (ZPL) processorconfigured to receive and process the format template; a variable dataintegrator configured to develop an association between the XML datacontained in the XML input data stream and the format template; aformatting engine configured to format the associated XML data accordingto a format governed by the format template; and a barcode renderingengine configured to receive the associated and formatted XML data andgenerate a printable representation of the bar code label, tag, ticket,card or other media or generate encoding information for the RFIDdevice.
 2. The system according to claim 1 wherein the XML processorgenerates a plurality of events based upon commands embedded in theformat template.
 3. The system according to claim 2 wherein the eventsare selected from the group consisting of a set printer speed event, setquantity of labels to print event, select media event, select ribbon touse event, choose paper event, use 300 dpi printer event, use 600 dpiprinter event, and variable data event.
 4. The system according to claim1 wherein the format template is sent to the XML processor and saved foruse with downloaded XML data, the XML data download at a subsequenttime.
 5. The system according to claim 1 wherein the format template isa ZPL-based format template.
 6. The system according to claim 1 whereinthe computer system reads data encoded in the RFID device.
 7. The systemaccording to claim 1, wherein the system further includes a hostcomputer operatively coupled to the network.
 8. The system according toclaim 6, wherein the system further includes a host computer operativelycoupled to the network.
 9. The system according to claim 8 wherein thedata read from the RFID device is transmitted to the host computer. 10.The system according to claim 1, wherein the system further includes aprinter operatively coupled to the computer system.
 11. The systemaccording to claim 10 wherein the printer is controlled according to aZPL-based printer control language.